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METHODS AND APPARATUS FOR NETWORK APPLICATIONS 
USING OBJECT TOOLS 

CROSS-REFERENCES TO RELATED APPLICATIONS 
This application claims the benefit of U.S. Provisional Application No. 
5 60/079,61 1 , filed March 27, 1998, hereby incorporated by reference. 

TECHNICAL FIELD 

The present invention relates, generally, to network groupware applications 
and, more particularly, to methods and apparatus for developing object-oriented 
systems in the context of non-object-oriented application environments. 

1 0 BACKGROUND ART AND TECHNICAL PROBLEMS 

Object oriented programming is a formal programming practice characterized 
by, among other things, encapsulation, inheritance, and object polymorphism. Due in 
part to the advantages of these characteristics, object oriented programming has 
quickly become the preferred software development paradigm. Notwithstanding this 

15 trend, modem enterprise groupware database systems remain tied, on the 
development level, to traditional programming techniques. Such systems, while 
powerful, are substantially aimed at providing ease of use for end-users, and therefore 
rely almost exclusively on simple graphical programming methods and flat-file 
functionality. Example enterprise groupware environments include, for example, the 

20 Lotus Notes application environment as described in the relevant system 
documentation, e.g., Lotus Notes Release 4 Application Developer's Guide (1 995), 
hereby incorporated by reference. 

The lack of modular and object oriented design standards in known groupware 
database applications gives rise to a number of problems. For example, application 

25 development time is often unnecessarily prolonged due to a lack of code reuse. That 
is, programming efficiency is decreased when custom modules must be created for 
a given application. In addition, it is often difficult to customize a particular section 
of code when such customization is desired. That is, because of the inherent non- 

- 1 - 
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modularity of typical enterprise groupware environments, altering one segment of 
code can unexpectedly impact on other sections of code in undesirable ways. 

Furthermore, programmers are not always disciplined with respect to naming 
standards for forms, views, fields, variables, and the like. As a result, other 
5 programmers (indeed, even the same programmer) may be confronted by names 
which are inconsistent and fail to describe the role of the particular component. This 
tends to increase development time, generate bugs, and frustrate code maintenance. 
Moreover, such inconsistencies tend to reduce code-sharing as it is often difficult for 
one programmer to understand, adapt, and maintain the code written by another. 
10 When clear software standards are not employed, quality control is very 

difficult to implement. Moreover, such coding tends to be inconsistent across 
application, resulting in variation in user interfaces experienced by the end user. Even 
when clear standards exist, it is extremely difficult and time-consuming to manually 
search through code to locate inconsistencies and bugs. 
1 5 Methods and apparatus are therefore needed to overcome these and other 

limitations in the prior art. 

SUMMARY OF THE INVENTION 
The present invention provides methods and apparatus for developing object- 
oriented network groupware applications in substantially non object-oriented 
20 programming environments. Object-oriented architectural and naming standards are 
used in conjunction with object repositories, an application builder, an application 
analyzer, a code fragment library, and development standards in order to create 
modular code, thereby addressing limitations of the prior art. 

In accordance with one aspect of the present invention, a method for using a 
25 programmable digital computer to create object-oriented applications within a non- 
object-oriented software environment includes the steps of: creating, in accordance 
with a predetermined set of design standards, an object within said non object- 
oriented software environment, wherein: said object comprises at least one of said 
design elements; said object is characterized by inbound public interfaces, outbound 
30 interfaces, and dependencies implemented using said design elements; transferring 
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said object to said application; and determining, for said object, a level of compliance 
to said predetermined set of design standards. 

BRIEF DESCRIPTION OF THE DRAWING FIGURES 
The subject invention will hereinafter be described in conjunction with the 
5 appended drawing figures, wherein like numerals denote like elements, and: 

Figure 1 shows a diagrammatic block diagram of an exemplary object tools 
system; 

Figure 2 shows a conceptual model of an exemplary object useful in illustrating 
the present invention; 

1 0 figure 3 is a flowchart depicting an exemplary application development process; 

Figure 4 shows a diagrammatic block diagram of an exemplary network 
environment; 

Figure 5 shows an exemplary application builder main menu; 
Figure 6 shows an exemplary menu for use in an "add objects" function; 
1 5 figure 7 shows an exemplary menu for use with a "remove objects" function; 

Figure 8 shows an exemplary menu for use with an "import new objects" 
function; 

Figure 9 shows an exemplary menu used to invoke an Application Analyzer in 
accordance with the present invention; 
20 Figure 10 presents a general guide to object model diagrams; and 

figure 11 shows an object model diagram corresponding to an exemplary 
architectural standard. 

DETAILED DESCRIPTION OF PREFERRED EXEMPLARY EMBODIMENTS 
25 A system in accordance with various aspects of the present invention includes 

methods and apparatus for developing object-oriented network groupware 
applications in substantially non object-oriented programming environments. With 
reference to Figure 1, an exemplary object tools system 100 includes Carrier 
Databases 102, Object Repositories 104, Application Builder 106, Code Fragment 
30 Library 110, Application Analyzer 114, and Analysis Template 112. All or some of 
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these components may be employed in creating the individual software applications 
108. In addition, an exemplary embodiment might include various tutorial and 
reference materials, e.g., user guide 118, example databases 120, and walk-through 
databases 1 22. An auxiliary file database may also be provided for storing ancillary 
5 files used by various objects, for example, graphic files, Java applets, and the like. 
It will be appreciated that Figure 1 presents a conceptual, diagrammatic overview of 
an exemplary object tools system in accordance with the present invention, and that 
suitable hardware and software components (e.g., servers, routers, data links, user 
computers, and the like) would be employed in order to implement the present system 
10 in a network environment. The specific geometry, topology, and labels used in 
Figure 1 are not intended to limit the scope of the present invention. 

Referring now to Figure 4, the present system is suitably implemented in a 
distributed enterprise environment comprising one or more servers 402, one or more 
developer workstations 405, and one or more user workstations 404 connected using 
1 5 appropriate data links 41 0 over a conventional network 408. The various objects and 
applications might be located within servers 402, user workstations 404, or a 
combination of both. Software development preferably takes place on developer 
workstations 406, but may alternatively take place at any other suitably configured 
workstation (e.g., servers 402 or user workstations 404). Servers 402 and user 
20 workstations 404 may comprise any suitable hardware/software configuration, for 
example, any of the various Intel Pentium-based computers or equivalents running in 
a Windows NT or Windows 95 environment , or various Sun Microsystem 
workstations running in a Solaris environment. In a preferred embodiment, developer 
workstations comprise a 32 bit Windows NT or Windows 95 workstation. 
25 Referring again to Figure 1, Carrier Databases 102 provide a mechanism 

through which the various objects may be distributed to end-users via e-mail, the 
Internet, or any other conventional data communication network. Carrier Databases 
1 02 allow objects to be shared between users and provide a efficient means for 
developers to distribute updated objects to users utilizing those objects in their 
30 applications. 
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Object Repositories 104 are preferably used to store the various design 
elements that comprise the objects used to build individual applications t08. User's 
may create their own Object Repositories 104, and common repositories may be 
provided, for example, as a location for archiving old and outdated objects. 
5 Application Builder 106 assists the developer in transferring objects within the 

system, and acts as an interface to Application Analyzer 1 14 and various standards 
and preferences related thereto. In an exemplary embodiment, Application Builder 106 
allows transfer of objects to and from Object Repositories 104, applications 108, and 
Carrier Databases 102. This allows the developer to easily add or remove objects 
10 from an application in a robust manner - i.e., in a way that is not likely to generate 
unexpected software bugs. 

Code Fragment Library 110 comprises small pieces of reusable code - 
preferably designed in accordance with standards set forth in greater detail below - 
which are typically not themselves complete functions or subroutines, but which can 
1 5 easily be copied into objects during application development. 

Application Analyzer 1 14 is preferably used to analyze individual or groups of 
applications 108 as well as the various objects that comprise those applications. In 
a preferred embodiment. Application Analyzer 114 creates a Result Document 116 
for each design element and object used in an application 108 and sorts these result 
20 Documents 1 1 6 into predefined categories for further analysis. Application Analyzer 
114 may also be used to identify any deviations from the preferred architectural and 
naming standards, thereby promoting standards compliance. In this way, Application 
Analyzer 114 facilitates efficient quality control, debugging, and preparation of 
documentation for applications 108. Documents 116 are preferably created in 
25 accordance with Analysis Template 112, which specifies a format for the various 
reports included in Result Documents 1 1 6. 

Objects 

Before discussing the various system components in detail, it is necessary to 
define the term "object" as used in the context of the present invention. As noted 
30 above, it is common for database environments - for example, Lotus Notes - to 
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provide user interfaces which are end-user-friendly, but which are not object-oriented, 
and therefore suffer from a number of development limitations as described above in 
the Background section. The present system utilizes the underlying elements of the 
database environment, but imposes upon them and profits from an object-oriented 
5 framework. 

Object-oriented frameworks offer a number of advantages. 
Having thus given a general overview of object-oriented programming, a 
method for employing object-oriented techniques in the context of the present 
invention will now be described. In the discussion that follows, the terminology 

1 0 popularized by Lotus Notes will be used throughout. Those skilled in the art, however, 
will appreciate that the present invention may be deployed in other database 
environments. For example, the meaning of "object" should not be construed to 
include only conventional Lotus Notes elements. Other object types (Dynamic HTML, 
APIs, query layouts, etc.) may also be employed. 

1 5 Referring now to Figure 2, in accordance with one embodiment of the present 

invention, an object may comprise any combination of forms 202, subforms 208, 
views 204, agents 206, navigators 210, and fields 21 2. An object may also comprise 
groups, roles, script subroutines or class definitions, graphics, or portable code files 
(not shown in Figure 2). 

20 Briefly, a form is a template, or window, through which the user may view 

database information. Forms, which are roughly analogous screen layouts, present 
data in a number of fields in a manner specified by the application developer. 

A subform is a type of form containing fields configured in an often-used layout . 
(for example, header information, navigation bars, and the like). 

25 A view is used to display database information in row and column format in 

order to assist the user in finding the desired information. A view may include data 
extracted from fields, results, or computation fields. A navigator may also be used to 
provide graphical assistance in finding data. 

A field contains a particular type of information, for example, text, rich-text, 

30 word lists, numbers, times, dates, user names, etc. In a typical application, a form 
presented to the user includes a number of fields, some of which are configured to 
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receive user input, and some of which are constant or a function of other fields or 
data. In addition, appropriate security conditions may be associated with a given field, 
sets of fields, documents, databases, applications, or data records. 

An agent is a component that automates certain functions within an 
5 application. For example, an agent may be employed to notify users of an impending 
due date, perform database maintenance, or perform various types data manipulation. 

Further information regarding these and other exemplary object elements may 
be found in a number of texts, for example, the Lotus Notes 4 Application Developer 
Guide referenced above. 
10 Given the exemplary set of object elements described above, the manner in 

which these elements may be employed in an object oriented environment will now 
be outlined. 

An important aspect of object-oriented systems is the distinction between 
private and public elements. An object is, by definition, functionally abstract - 

1 5 meaning that while its functions and public interfaces are quite clear in usage, its 
internal workings are not necessarily clear or even known to the user. In the present 
invention, design elements (forms, views, etc.) may be designated as public or 
private, and fields themselves may also be public or private. That is, certain forms, 
views, subforms, agents, and navigators may be used by the object itself, or may be 

20 used by other objects as well. Similarly, certain fields may be public (referred to as 
"out-bound public interfaces") or private (in which case they must not be referred to 
by any other object). For example, in Figure 2, field 212(a) is illustrated as public, 
while field 212(b) is illustrated as private. 

In the context of the present invention, objects receive input through fields, 

25 referred to as "in-bound public interfaces." These fields are created and maintained 
in the referring code, not the object itself. For example, field 212(a) shown in Figure 
2 may be an out-bound public interface to another object which uses the value of 
field 212(a) as an in-bound public interface to an internal algorithm. 
Objects may also receive inputs from documents, i.e., they may retrieve input from 

30 data stored elsewhere in the database. 
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In accordance with a the present methodology, an object should not be thought 
of as simply a field, or an agent, or as any particular element. Instead, an object is a 
function or component whose behavior and implementation is defined as a collection 
of design elements and properties. This provides a mechanism which makes it easy 
5 to define complex objects that are not pure instances of one element. A particular 
object might exist in only one part of the environment, or it might extend into several 
parts of the environment. For example, a basic field object might only exist in the field 
and form parts of the environment, whereas a object free-time search algorithm 
would probably involve fields, views, agents, buttons, and layout regions. 
1 0 Interfaces are essentially any location that you can put code in the underlying 

groupware application, for example, events, view selection formulas, agents, script 
subroutines, navigators, icons, properties, screen "hot-spots," and the like. 

Development Process 

Having thus given a general overview of objects as well as various components 
15 comprising an exemplary object tools system 100, an overview of an exemplary 
development process in accordance with various aspects of the present invention will 
now be described. 

Referring now to Figure 3, a developer typically begins a design session in one 
of three ways. First, a developer may utilize a Carrier Database 102 to share 

20 preexisting objects with another Developer (Step 304). Alternatively, the developer 
may proceed directly to invoking Application Builder 106 (Step 310), or may modify 
or debug a pre-existing object (Step 308). 

In Step 304, one or more Carrier Databases 1 02 are preferably utilized as a 
vehicle for assembling new or modified objects prior to inclusion in an Object 

25 Repository 104. Carrier Databases 102 are preferably created from a carrier database 
template residing in a suitable location within the system. The developer preferably 
populates the Object Repository 104 with at least the following items: 1) design 
elements used by the object, 2) documentation for the object, and 3) an object map 
document (listing object names, object IDs, design elements, interfaces, and the like). 
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In Step 308, the developer assembles and configures the various forms, 
subforms, views, agents, navigators, and fields that are required for a particular 
application. These design elements are preferably created, named, and configured in 
accordance with architectural and naming standards described in detail below. 
5 In Step 310, the developer invokes Application Builder 106. As mentioned 

briefly above, Application Builder 106 supports modularity by assisting the developer 
in transferring objects in a robust manner. In addition, Application Builder 106 acts 
as an interface to Application Analyzer 1 14 and Code Fragment Library 1 10 and can 
be used to define other interfaces created by the developer. In an exemplary 

10 embodiment, Application Builder 106 allows transfer of objects to and from Object 
Repositories 104, applications 108, and Carrier Databases 102. Specifically, when 
the developer initiates Application Builder 106, the system presents a suitable 
graphical interface for selecting from a plurality of functions. In an exemplary 
embodiment, a main menu screen such as that shown in Figure 5 is displayed, 

1 5 offering at least four choices: add objects 502, remove objects 504, import objects 
506, and run Application Analyzer 508. If the developer selects the "add objects" 
function (502), a second, more detailed input screen is displayed, for example, an 
input screen as shown in Figure 6. Here, the developer selects the appropriate 
application to which the objects will be added (602), selects the objects to be added 

20 (604), and implements the addition with certain options (606). In this way, the 
developer is able to transfer objects from various Object Repositories to the 
application of interest (items 104 and 108 in Figure 1 respectively). 

Referring again to Figure 5, "remove objects" function 504 allows the 
developer to remove unwanted or unneeded objects from an application. A variety of 

25 interfaces to this function may be appropriate - for example, an interface as shown 
in Figure 7. More particularly, in the illustrated embodiment, one or more menu 
screens suitably provide an input region 702 for selecting an application from which 
objects are to be removed, an input region 704 for selecting objects to removed, a 
region 706 for activating the remove function, and an input region 708 for reviewing 

30 a log of past removal operations. 
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"Import objects" function 506 suitably allows the developer to move an objects 
design elements, documentation, and object map from a Carrier Database 102 to an 
Object Repository 1 04. A variety of user interfaces may be employed to carry out this 
function. In an illustrated embodiment, one or more menu screens provide a region 
5 802 for selecting an Object Carrier from which objects will be imported, a region 804 
for selecting a Repository to which objects will be transferred, a region 806 for 
specifying the location of the applicable user guide (i.e., documentation such as 
object models, required elements, and the like), a region 808 for choosing object 
types (i.e., subsets of available objects), a region 810 for activating the import 

10 function, and an input region 81 2 for reviewing the log. 

Application Builder 108 also suitably provides an option for accessing the Code 
Fragment Library 1 10 (function 510). It will be appreciated that the various functions 
presented by the illustrated Application Builder 1 06 may alternatively be distributed 
between multiple software programs using any number of different user interfaces. 

15 In cases where objects are added to an application, the developer may be 

required - in accordance with certain architectural standards as detailed below - to 
modify or add objects, fields, forms, or other design elements. Such required 
modifications are specified in the documentation via an object map associated with 
a given object. More particularly, documentation associated with each existing object 

20 preferably sets forth a list of objects comprising that object, and specifies the required 
and optional inputs for each form. These inputs, or inbound public interfaces, are then 
supplied by the developer within the object or form being created. The documentation 
further specifies any dependent objects which must be copied (using Application 
Builder 106) and suitably configured. 

25 "Run application analyzer" function 508 suitably invokes the Application. (Step 

312). As mentioned briefly above, Application Analyzer 114 is preferably used to 
analyze individual or groups of applications 1 08 as well as the various objects that 
comprise those applications. In a preferred embodiment, Application Analyzer 114 
creates a result document 116 for each design element and object used in an 

30 application 108 and sorts these documents 1 1 6 into predefined categories for further 
analysis. Application Analyzer 1 14 is also used to identify any deviations from the 
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preferred architectural and naming standards set forth below, thereby promoting 
standards compliance. In addition, Application Analyzer 114 may be used to 
incorporate various standards developed within an end-user's organization, assess an 
application's Year-2000 compliance, and/or search for non-applicable or obsolete 
5 functions or code. 

In an exemplary embodiment, Application Analyzer 1 1 4 is invoked through 
Application Builder 106, for example, as shown in Figure 5, where function 508 
provides an entry point into the analyzer. Running Application Analyzer 114 (Step 
312) involves selecting an application to analyze (through selection of the appropriate 

10 server and file path name), selecting an analysis file to which the results will be 
posted, then selecting various options as desired (for example, choosing whether 
incremental analysis should be performed and whether the objects themselves should 
be checked). More particularly, an illustrated embodiment employs one or more menu 
screens as shown in figure 9 wherein the user/developer is presented with an input 

1 5 region 902 for selecting the application, input region 904 for selecting an analysis 
file, and a region 906 for invoking the analyze function. 

When the analysis is complete. Application Analyzer 1 14 preferably creates a 
Result Document 116 for developer review which lists various data helpful in 
debugging and documenting the application in question (Step 314). Specifically, 

20 Application Analyzer 1 1 4 preferably lists the various inspected objects along with any 
naming or architectural standards that have been violated. 

After reviewing the results of the Application Analyzer, the developer may 
choose to debug the application under development to reconcile any deviations from 
the architectural or naming standards (Step 316). Thus, the developer may choose 

25 to return to the Step 302 (or, most likely, Step 306) to continue refining and 
developing the application or various objects within the application. 

Standards 

As mentioned above, one aspect of the present invention relates to an 
advantageous set of standards imposed on object development which are "enforced" 
30 via Application Analyzer 114. These standards are aimed primarily at producing 
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readable code, facilitating easy debugging, encouraging code reuse, and enhancing 
modularity. In general, standards used in the context of the present invention can be 
categorized as either naming standards or architecture standards. 

Naming standards involve rules used in conjunction with design elements 
5 (forms, views, etc.) which are intended to incorporate into the element's name some 
indication of the purpose and/or source of the element. Architecture standards relate 
to, among other things, framework or "kernel" objects and design elements which are 
required in all or most applications. In addition to naming standards and architectural 
standards, certain visual standards related to text and graphics layouts may also be 
1 0 desirable. 

With respect to naming standards, each object is preferably named in such a 
way as to affect the various goals of the present invention. In a preferred 
embodiment, the object name is constructed as: 

< element prefix > < object ID>-<element name>, or 
15 < element prefix > < object ID >< instance number > < element name > , 

wherein the size and description of each component is specified in Table 1 below. 
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5 



Component 


Number of 
Characters 


Description 


< element 
prefix > 


Two or Three 


Describes what the element is and how it is used. 
Most types of design elements have several 
possible prefixes. 


< object ID> 


Six 

(with leading 
zeros and 
trailing x's if 
needed) 


A 1 inintIO If^ that ie accinnnrl _ -UI«*A r ^ _ 

" unique iu tnai is assigned to the object for 
identification purposes. All design elements that 
are part of the same object have the same object 
ID in their names. This enables programmers and 
automated tools to easily determine the object to 
which a design element belonqs. 


Hyphen or 
< instance 
number > 


One 


A hyphen is used mainly for visual distinction 
between the prefix and the descriptive part of the 
name, making it easier to read a list of design 
element names. 

An "instance number" is used when multiple 
copies of an element in one database are needed. 
For example, there may be a need for two 
subforms which are substantially identical and 
serve the same purpose but must have different 
names so that they may be used together on the 

coma form 

same Torm. 

The instance number is preferably a single digit, 0 
through 9. If more than 1 0 instance numbers are 
needed, lowercase alphabetic characters should be 
used. 


< element 
name> 


Variable 


Descriptive name for the design element which 
identifies what the element is used for. 

Mixed na^p with thp fimt lot-tor n-f aq^k ir>r* + 
iniAcu uaoc wiiii li ic nidi iciLci or eacn Qisxincx 

word capitalized. May include valid punctuation 

characters, but no spaces, avoiding certain 

symbols and punctuation characters (e.g., * W#", 

and "**) which may cause problems for Web 

clients. 



TABLE 1 



Object prefixes are preferably specified for each class and type of design 
elements. In the case of view elements, prefixes are suitably chosen in accordance 
with Table 2 below. 
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5 



Prefix 


Comment 


cal 


A calendar view, visible to the user. 


db 


A view used internally by the application for lookups or other 
processing. Not visible to the user. 


fol 


A folder, visible to the user. 


vdb 


A view used internally and also seen by users (such as views used in 
pick-lists). 


w 


Views visible to the user. Not used for any other purpose, such as 
lookups, iteratinq through a set of documents, etc. 



TABLE 2 



For example, the name "dbAC0012-Partl\lumberLookup" may be used in 
conjunction an internal look-up table view specifying a list of part numbers. 

It may be desirable to create separate hidden views for users and for any 
internal processing views performed by an application, making it more convenient to 
alter the design of elements apparent to the user without affecting the code, thereby 
reducing the possibility of introducing errors. The "wVcalVfor and "db" prefixes 
are designed to make this distinction clear. 

For visible views (i.e., views which appear on the View menu or the 
View/Folders pane) the IOT name is preferably used as the view's alias, as in "All 
Parts\By Size | wAC001 2-AIIPartsBySize". 

In a preferred embodiment, element prefixes for forms are selected in 
accordance with Table 3 below. 
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Prefix 


Comment 


doc 


Regular document form 


res 


Response form 


rtr 


Response-to-response form 


dig 


Document form used for a dialog box 


ntp 

nav (obsolete) 


Form used for a navigator template 


vtp 


Form used for a view template j 


vsr 


Form used for a Search Results Template 



10 TABLE 3 

For forms whose names will not appear on the "Create" menu, object names 
with no aliases are preferably used (e.g., "resOOOOOO-CustomerComment"). For 
forms whose name will appear on the "Create" menu, the format "Create Customer 
Comment | resOOOOOO-CustomerComment" is preferably used. If in the context of 
15 a specific enterprise software system an alias is required (as might be the case with 
Notes or Domino), the alias is preferably placed to the right of the object name, for 
example: "ntpAC0012-StandardWebUI | $$NavigatorTemplateDefault." 

In a preferred embodiment, element prefixes for subforms are selected in 
accordance with Table 4 below. 



Prefix 


Comment 


sub 


Regular subform 



TABLE 4 



For subforms, aliases are not needed, and only the object name need be used 
(for example: "sub0034xx-StandardDocumentHeader"). 
25 Script Libraries preferably employ a single element prefix as specified in Table 5 

below. 
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Prefix 


Comment 


scl 


A script library 



TABLE 5 



As with subforms, script libraries do not require aliases. For script libraries that 
5 contain a single class definition (with or without derived classes), the convention of 
naming the library with "class" plus the class name is preferably used. 

Navigators preferably use a single element prefix as specified in Table 6 below. 



Prefix 


Comment 


nav 


A navigator 



10 TABLE 6 

There are preferably two types of navigator naming schemes - one for 
navigators that will appear on the ViewXShow menu, and one that will not. For 
navigators whose names will appear on the ViewXShow menu, an alias is preferably 
used, for example, "End User Menu | navAC8020~EndllserMenu". For navigator 
15 names that will not appear on the ViewXShow menu, the object name within 
parenthesis is preferably used, as in "(navAC0820-ConfigMenur. 

In an illustrated embodiment a more complex prefix scheme is used for agents 
since each one of the three characters in an agent prefix has a distinct meaning. More 
particularly, the first character identifies how the agent is triggered; the second 
20 character identifies how often the agent should run if it is a scheduled agent; and the 
third character identifies the documents to be processed (i.e., the "run on" setting). 

Preferred characters for the first, second, and third places of the agent prefix 
are specified in Tables 7, 8 r and 9 respectively. 
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First Prefix 
Character 


How the Agent is Triggered 


s 


Scheduled background agent 


t 


Action menu or @Command([ToolsRunMacro]..) 


a 


Called by another agent 


m 


When documents are mailed to the database/new mail 


P 


When documents are pasted 


V 


Domino QuerySave agent 


o 


Domino QueryOpen aqent 


TABLE 7 


Second 

Prefix 

Character 


How the Agent is Scheduled 


X 


Placeholder if the agent is not a scheduled agent 


h 


Scheduled agent runs hourly 


d 


Scheduled agent runs daily 


w 


Scheduled agent runs weekly 


m 


Scheduled agent runs monthly 


0 


Scheduled agent runs every half hour 


1 


Scheduled agent runs every hour 


2 


Scheduled agent runs every two hours 


4 


Scheduled agent runs every four hours 


8 


Scheduled aqent runs every eight hours 



TABLE 8 
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Third Prefix 
Character 


Type of Document Agent Runs On 


a 


All documents in the database 


m 


Runs on newly mailed documents 


n 


New and modified documents (i.e., the agent's unread marks) 


P 


Runs on pasted documents 


u 


Unread documents (i.e., the user's unread marks) 


V 


All documents in the view 


s 


Selected documents 


r 


Run once 



TABLE 9 



If the agent is specified to run at a fixed frequency, the digits 0-8 are preferably 
used for the second character. However, if the agent can be set by the user to run 
at a different frequency, the letter "h" ("hourly") is preferably used. For scheduled 
1 5 agents, the letters preferably "a" and "n" are used for the third character of the 
prefix. 

Agent aliases can be complex, particularly in the context of Notes, since Notes 
itself will modify the agent name when the agent is set to "Run From Agent List." For 
agents whose names will appear on the Actions menu, an alias format such as 

20 "Process Sales Leads | txsAC8020-ExportLeads" is preferably used. For agents 
whose names are to appear on the View\Show menu, the object name is preferably 
used within parenthesis, for example: "(txrAC0820-ConfirmationPrompt)". 

An alternate way to hide an agent is to set its run option to "Manually From 
Agent List." Notes will modify the names of such agents to include the parenthesis 

25 automatically. Aliases should not be used when naming these agents, as they are not 
necessary: the I0T name alone is preferably used. 

In the illustrated embodiment, Object IDs are specified as comprising exactly 
six characters, wherein a character may consist of a letter (upper case or lower case) 
and some symbols. For readability purposes, it is advantageous to limit characters to 

30 upper case letters and numbers, using lower-case "x"s as place-holders where 
necessary (for example, H 0123xx", TESTxx", etc.) In this regard. Table 10 sets 
forth a preferred object ID naming scheme, where denotes any alphanumeric 
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character. 



ID 


Description 


000000 


An all-zero object ID indicates a design element that is not 
associated with a reusable object. These are most commonly used 
for elements that are specific to an application. 


0001?? 
through 
9999?? 


Object IDs that begin with four numeric characters may be reserved 
for use by the development software and other products 


A????? 
through 

Z????? 


Object IDs in this range are available for developers to assign to 
objects in custom repositories. For example, if the developer's 
corporate initials are n AC w the developer might assign IDs in the 
sequence "ACOOOT through n AC9999" to be custom objects. 


TEMP?? 

DEMO?? 

TEST?? 


Object IDs that begin with these characters are used for elements 
that are not intended to become part of a finished application or 
object. The Application Analyzer preferably warns the developer 
when it comes across such an ID. 



TABLE 10 



A Notes field name is constructed as: 
5 < purpose > <list> < datatype prefix > {object ID} < field name> , or 

< purpose >< list >< datatype prefix > < instance number > {object ID} < field name > . 

Table 11 below sets forth a description of each of these components in 
accordance with a preferred embodiment of the present invention. 



- 19- 



WO 99/50756 . 



PCTAJS99/06126 



v^omponeni 


Number of 


uescnpuon 


< purpose > 


Zero or One 


ndicates whether the field is used in any special 
context, such as a local variable. There are only 
a few cases where the purpose character is used. 


<list> 


Zero or One 


A lower case 1 for fields that can contain 
multiple values. 


< datatype 
prefix > 


One to Four 


ndicates the data type stored in the field. This 
tag covers all the Notes field data types (Text, 
Number, Rich Text, etc.) and also includes some 
additional ones where more detail is needed. 


Underscore or 
< instance 
number > 


One 


The hyphen is used mainly for visual distinction 
between the prefix and the descriptive part of the 
name, making it easier to read field names. 

An instance number is used when there is a need 
to have multiple copies of a field in a database. 
For example, there may be a need for two 
computed-for-display fields to display the same 
information in multiple places. One might be 
named "dtxtlPhoneNumber," the other 

"rlfvtOPhnnaMi imhor " moUnn if* Hoar tHsYt* thou 

OiXXZr nonei>iumDer, rrtaKjng il ciear inai uiey 
are intended to show the same information. 

The instance number must be a single digit, 0 
through 9. If more than 10 instance number are 
required, lowercase alphabetic characters may be 
used. 


{object ID} 


Zero or Six 


Optional component: used only when there is a 
chance that a field name in one object will 
duplicate one in another object. Note that if 
descriptive field names are chosen, the chances 
of name-collision are minimal. 


< field 
name> 


Variable, up 
to the limit for 
field names 


Indicates the purpose or content of the field. A 
descriptive, self-documenting name is preferably 
used. The convention is to use mixed-case, and 
to capitalize the initial letter of each word. 
Spaces, punctuation, and most symbols are 
preferably hot used. 



TABLE 1 1 



It should be appreciated that, for CGI surrogate variables (i.e., variables using the 
prefix "HTTP _"). capital letters should be used in order to duplicate the precise name 
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of the CGI variable. Examples field names in accordance with the above scheme 
include: "txtJDriginalAuthor" for a regular text field; "numJ\CME54CurrentPrice w for 
a numeric field belonging to Acme object 54; and "dlnamStateApprovers" for a 
multi-value, computed-for-display name field. 
5 As mentioned briefly above, the first component for a field name is the Purpose 

identifier. In a preferred embodiment, purpose identifiers conform to the standards set 
forth in Table 12 below. 



Purpose 
Identifier 


* 

Comment 


d 


Field is computed-for-display 


V 


Local variable that is used internally in a formula, and does not 
correspond to a field 


k 


Key field (not to be confused with a keyword field) which uniquely 
identifies a document 


f 


Foreign key field (another document's key field value) 


<none> 


None of the above 



15 TABLE 12 

Example Purpose identifiers in accordance with this system include: 
"dtxtPhoneNumber" for a computed-for-display field; "vnam_CurrentAuthor : = 
namDocAuthor" for a local variable in an ©Formula being set to the value of a field 
on the current document; and "ktxtEmployeeSSIST for a field containing a unique 
20 identifier for the document. 

The second component for a field name is the Data Type prefix. Data Type 
prefixes preferably conform to the scheme set forth in Table 13 below. 
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/Ola 






'vne 

dentifier 


Comment , _ 




txt 


Text field 


5 


tim 


Date/time field 




num 


Number field 




sec j 


Section field 




aut 


Author Names field 




rdr 


Reader Names field 


10 


nam 


Slames field ■ — 


rtf 
I LI 


Rirh-tf*vt field 




html 

nimi 


T*>vt fi*»»H mntaininn an HTML strina (Hypertext Mark-up Language) 




HTTP 


Text field corresponding to a CGI variable (Common Gateway 




UTTDC 


inTerracei _ _ » 


15 


url 


Field that contains a World Wide Web URL (Uniform Resource 
Locator; 




vn 


Field that has either a "Yes" or a w No tt value 




f 


Numeric field that has a Boolean value of either @True or @False. 
"f w stands for flag. _ , 




unid 


ToYt fif»irl that rnntains a Notes Document Unique ID 

I cXl IICIU Midi vA/l I LCI ll lo a ■> ~i 

(@ DocumentUniquelD) 


20 


list 

(obsolete) 


A multi-value text field. The current standard uses a lowercase T 
before the datatype prefix to indicate multi-value fields instead of this 
obsolete prefix. . 




nid 


\Jext field that contains a Note ID «p>NotelD) 



TABLE 13 



Example Data Type prefixes in accordance with these rules include: 
"numJEdrtCounter", -tim_Created", "html_AppletTag", "rtf_Body", and 

25 "HTTPHOSTNAME". 

Object Identifier fields may be used to detect the presence of an object within 
a document. For example, if an object designated as "IIO0033 Expiration" is used 
on a form, documents created with that form will contain a field named "IIO0033." 
The Expiration agent, or any other object in the application, can then detect such 

30 documents using a selection formula such as "SELECT @lsAvailable(IIO0033)". 
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Object Identifier fields preferably consist of an object ID and an optional 
descriptive label in the format: 

< object ID> 
or, 

5 < object ID >_< label > 

In a preferred embodiment, Object Identifier fields are always text fields, and 
are usually computed-when-composed. Any object that includes either a form or a 
subform should include an object identifier field, typically placed at the top of the 
form or subform. Since complex objects may consist of several types of documents, 
1 0 an object may have more than one object identifier field. 

With respect to Script variables, there are generally two types: (1) Variables of 
fundamental data types, such as Integer, Double, String, Lists, Arrays and user- 
defined types; and (2)Variables that refer to an instance of a class, i.e., an object 
variable declared to be a NotesDocument, NotesDatabase, or some other class. 
1 5 Names for fundamental data type scripts are preferably constructed as follows: 

<scope/parametertype><aggregatetype><datatypeprefix>_<variablename>{suffix} . 

while names for instance variables are constructed as: 

<scope/parameter type> <aggregate type> <class prefix >_< variable name> {suffix} , 
or, in an abbreviated form: 
20 < scope/parameter type > < aggregate type > < class prefix > {_suff ix} . 

Script components preferably conform to the guidelines set forth in Table 14. 
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5 



Component |C 


lumber of 
:haracters C 


)escription . J 


< scope/parameter |2 
type> J 


lero or One 1 " 
f 
It 

It 

i 
1 

n 


Scope" is the visibility of the variable in aj 
unction/procedure. For example, variables may 
)e defined locally or globally. 

Jsing a prefix for scope is especially important 
n LotusScript where the global module is well 
lidden, as one might wonder where specific 
variables have been declared. 1 

w < parameter type>" refers to how a parameter 
appears in a function or subroutine; either "by 
reference or by value. ine aisuncuun 10 
important because changes to a "by reference" 
parameter can have inadvertent side-effects 
beyond the scope of a given function. 1 


< aggregate type > 


Zero or One 


Used to identify variables of the built-in 
"Aqqregate" data types: arrays and lists. 


<data tvoe 
prefix > 


One to Four 1 


Indicates the fundamental type of the variable. 
In addition to the basic data types like String and 
Integer, the system may define some extra 
prefixes for convenient types. 

Preferably never used in conjunction with a 
< class prefix > . 


< class prefix > 


[Three to Six 


Indicates the class to which an object variable 
belongs. Some user-defined classes may specify 
a < class prefix > to use for instances of that 
class, but it is not required. If no class prefix is 
1 defined for objects of a given class, the "obj"l 
prefix should be used instead. Preferably never 
used in conjunction with a <data type prefix > . J 


Underscore 


lOne 


For readability, the underscore character comes 
between the data type or class prefix and the 
descriptive name. 


< variable name> 


Variable, up 
to the limit 
for Script 
variable 
names 


The descriptive name of the variable. Preferably 

mivAri r>»cp with initial caoitals on distinct 1 
l use mixeu coots wuu hhuoi v»u^i».m«m ■ 

words. The variable name can be omitted if it is j 

clear that there is only one possible instance of 

a variable of that type. 


) {suffix} 


Variable 


Optional, but quite convenient to use for 
1 naming variables. , 1 



TABLE 14 
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Scope/Paromote, Types p-e«era bl y conform to *. guktoUnes se, forth in 
Tables 15 and 16 below. 



10 




Variable is a reference parameter in a function/procedure. Reference 
S£ im theirvalues to the calling function/procedure. Th.s 
js the default in LotusScript 



not return 



th»ir values to th« ^"ino f unction/procedure. 



TABLE 16 



Aggregate Types 



preferably conform to the guidelines set forth in Table 17 below. 



15 




Variable is a 



Iis t (NOTE: Lotus Script lists are different from , Notes 




TABLE 17 



20 Data Type prefixes, Object Cass prefixes, and Suffix prefixes preferab.y 

conform to guidelines set forth in Tables 18, 19. and 20 below. 



- 25 - 



WOW/50756 



PCT/US99/06126 



Data 
Type 


Comment : 


dbl 


Double precision floating point number m 


cnn 


Sinale precision floating point number m _ 




Currency _ — — 


Ina 


Long integer - " — 


int 


Integer ____ ■ — 


f 


An Integer variable containing either True or False. 

w f w stands for "flag variable" — - 


var 


Variant m . - — 


dat 


Date/Time - — . — 


str 


String — — 


tVP 


A variable whose type is a user-defined data type, _ 1 



TABLE 18 
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[Object 
Class 

Prefixes ( 


Comment 


lobj 
1 

1 


Variables that are instances of user-defined classes, or of classes that 

rift nrvf ha\/p an flCcnoiatAH da*?*; nrfifix 

For example, "obj AnalysisDoc" would indicate an instance of the user- 
defined class "class AnalysisDoc". 


nacl 


NotesACL 


nacle 


NotesACL Entry 


jnagt 


NotesAgent * 


ndb 


NotesDatabase * 


ndt 


NotesDateTime 


ndir 


NotesDbDirectory 


ndoc 


NotesDocument 


Indtr 


NotesDateRange 


ncol 


NotesDocumentCollection 


neo 


NotesEmbeddedObject 


nfrm 


NotesForm * 


Inintl 


Noteslnternational 


Initm 


Notesltem * 


jnlog 


NotesLog 


jnnam 


NotesName 


nnews 


NotesNewsletter 


nreg 


NotesRegistration 


nrsty 


NotesRichTextStyle 


Jnrti 


NotesRichTextltem * 


Inses 


NotesSession 


Intmr 


NotesTimer 


nuidb 


NotesUI Database 


1 nuidoc 

1 1 ImIuvw 


NotesUI Document 


1 nt liv/w 

1 1 IUIV w 


hlntf*^l J IVip w 


1 ni ii\A/Qn 


NntpQt J IWorlcsnace 


1 nwvAV 
1 1 IV w 


Mntp«;\/ipw fit k nreferahle to name obiects that have corresponding Notes 
element or field names by using the same descriptive name both in the Notes 
database and in Script ). 


nvcol 


NotesViewColumn 


oconn 


ODBCConnection 


oqry 


ODBCQuery 


ores 


ODBCResultSet 



TABLE 19 
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Data 
Type 


Comment 


Cur 


Current element (e.g. of array, result set, list etc.) 


First 


First element 


Last 


Last element 


Next 


Next element _ 


Prev 


Previous element 


Min 


Lower limit of range (e.g. of an array) 


Max 


Upper limit of range 


Src 


Source (e.g. of copy operation) 


Dest 


Destination 


Old 


Old element 


New 


New element 


Temp 


Temporary element 



15 TABLE 20 



Example script variable names in accordance with these guidelines include: 
"gdatActual" for a global date/time variable; "ndocCur" for a "current" document 
in a loop; "Ist^CustomerlDs" for a list of strings; and "gatypJV/lyArrayJ )' for a global 
array of a user-defined type. 
20 A LotusScript constant name is preferably constructed as: 

<scope> <data type prefix >_< CONSTANT NAME> 
wherein the name components conform to the standards set forth in Table 21 below. 



Component 


Description 


< scope > 


H g w for global, "m w for module, or omitted for local constants 


<data type 
prefix > 


One of the data type prefixes defined for Script variables. 


< CONSTANT 
NAME> 


Description of the constant name. Use all capital letters, with 
distinct words separated by underscores. 



TABLE 21 
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Example constant names include: "gnum_HOLIDAYS_PER_YEAR" for a global numeric 
constant; and "str_JANUARY" for a string constant named "January". Similarly, user 
defined type names are preferably constructed as: 

type_<type name> , and 
5 class names are preferably constructed as: 

class_< class name> . 
Functions are also preferably given data type prefixes to reflect the type of value the 
function returns, i.e.: 

<data type prefix >_< function name> , 
10 wherein the data type prefixes for function names are identical to those for script 
variables set forth above {for example: Function int_DaysBetweenDates(rdat_Rrst as 
Variant, rdat_Last as Variant) As Integer). 

ft rr frtftr.tiira> Standards 

As mentioned briefly above, a system in accordance with the present invention 
15 provides and enforces a set of advantageous architectural standards which are 
imposed on the development process, thereby affecting the larger goal of providing 
object-oriented functionality in the context of a non-object-oriented software 
environment. Architectural standards relate to, among other things, framework or 
"kernel" objects and design elements which are required in all or most applications. 
20 Architectural standards are preferably documented and communicated 

graphically via an object modeling technique (OMT). In the present context, an OMT 
(for example, the Unified Model Language, or UML) is a technique for representing 
design elements and the relationships between those elements in a concise graphical 
format. The OMT diagrams can be though of as "blueprints" for the objects. 
25 Referring now to Figure 10, OMT notation involves the use of bi-level boxes 

to represent design elements, wherein the top box (e.g., 1001) includes the name of 
the element, and the bottom box (e.g., 1003) sets forth various attributes of the 
element, if appropriate. Boxes that do not include a design element name are referred 
to as "abstract," and represent either other objects, groups of elements, interfaces, 
30 or non-implemented (virtual) base classes. Relationships between objects are 
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designated by lines (e.g., 1005), which may or may not have an associated 
descriptive label. The nature of the relationship between two elements is denoted by 
the use of particular symbols at one or more endpoints of the line. More particularly, 
with continued reference to the graphical conventions shown in Figure 10, a 
5 one-to-one association {1 002) indicates that element A is associated with exactly one 
B; a zero-or-more association (1004) indicates that A is associated with zero or more 
Bs; a one-or-more association (1006) indicates that A is associated with one or more 
Bs; a Zero-or-one association (1008) indicates that A is associated with zero or one 
Bs; a "Has a" relationship (1 01 0) indicates that A comprises a B and a C (e.g., where 
10 A is a form, and B and C are subforms); and an "Is a" relationship (1012) indicates 
that B is an A and C is an A (potentially used with forms and subforms). 

Object Model diagrams, which comprise part of an object's documentation, are 
suitably used by the developer to determine the design elements contained in a given 
object. That is, all objects and applications are preferably created within a particular 
1 5 template of required fields, required objects, and required roles. Moreover, objects are 
created in accordance with a preferred element order (e.g., subform order).Each of 
these architectural aspects will now be described in turn. 

On a large scale, all applications preferably conform to a structure which will 
best exploit an object-oriented methodology when used in the context of the various 
20 components of the present system. In a preferred embodiment, for example, all 
applications conform to the system-level object model set forth in Figure 11. 
Specifically, an application (or database) 1 102 "has a" Configuration object 1 104, All 
View object 1106, and Standard View Template 1108. Application 1102 also has 
one or more form objects 1110, wherein form object 1 1 1 0 is a Response Form 1 1 30, 
25 and has: zero or one Return objects 1 1 20; zero or one Edit History objects 1 1 22; zero 
or one Standard Action Buttons objects 1 1 24; a Document ACL object 1 1 26; and a 
Standard Subforms object 1 128. 

Configuration object 1 104 preferably provides the standard configuration and 
setup mechanism for applications. It's main purpose is to allow developers to easily 
30 expose configuration controls to users, and to do so in a standard, modular way. 
Configuration object 1104 preferably comprises objects for storing configuration 
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settings related to the application as well as choices shown to users in keyword 
fields. Configuration object 1104 also preferably comprises a standard database 
configuration subform containing common settings, views for accessing configuration 
documents, and support for roles which control author access to documents. 
5 All view object 1106 preferably provides a standard view for examining all 

documents in a database. This can be used by a user or developer for debugging 
purposes, or can be used in conjunction with script or HTML commands (e.g., 
LotusScript or Domino URLs) for programming purposes. 

Standard View Template 1 108 preferably comprises forms and action buttons 
10 designed to give a standard look and feel for all the views and search results pages 
in an application. This is particularly desirable in cases where the subject application 
is accessible to web clients. 

Return object 1 1 20 is preferably used to provide a return field to objects which 
call the form. The return field - which may concatenate information received from 
1 5 multiple objects in a form - may comprise information related to HTML code, an URL, 
a link back to the current document, or even background color of the returned page. 

Edit History object 1 1 22 is preferably used to retain a chronological list of 
editors for the particular document. In a preferred embodiment. Edit History object 
1 1 22 stores the edit history in a single field rather than a plurality of fields; this 
20 scheme eases the addition of new entries, provides flexibility with respect to the edit 
history data structure, and helps control disk space use. 

Standard Action Buttons object 1124 preferably comprises a subform 
containing a number of common action buttons, for example, "Save", "Close", "Edit", 
"Delete", "Previous/Next", and E-mail feedback. The use of such a subform helps 
25 provide consistency across documents and across applications. 

Document ACL object 1 1 26 provides standardized control over Reader and 
Author fields needed in an object-oriented application. This object preferably accepts 
input from other objects and grants author access to all documents in accordance 
with specified access conditions (e.g., through the use of a standard role. Among 
30 other things. Document ACL object 1 1 26 simplifies the task of troubleshooting with 
respect to access control problems. 
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Standard Subforms object 1128 preferably comprises a set of standard 
subforms, for example, a standard header subform (including a unique document ID, 
an author code, modification dates, and the like) and a standard footer subform. 
In addition to required objects, development standards might include one or 

5 more required fields. Such fields might be used, for example, to communicate 
information to the user. In an illustrated embodiment, two fields are required for all 
applications: txtJDocSummary and txtResponseUne. The txtDocSummary field 
suitably contains a one line summary of the document contents. Agents and views 
can use this field to describe the document to the user. The txt_ResponseLine field 

10 is suitably used on all response documents. It should contain a one line summary of 
the content of the response document. This field is used by views in response only 
columns. 

Architectural standards might also specify the order of elements that appear 
in an object, particularly when a form comprises one or more subforms. For example, 
1 5 with reference to the various elements described above in connection with Figure 11, 
the following order of elements is suitable: 

1 . Standard Document Header subform 

2. Standard Document Action Buttons 

3 . < Form-Specific elements > 
20 4. Horizontal Divider element 

5. Document ACL object 

6. Edit History object 

7. Standard Document Footer 

8. Return object 

25 In addition to required objects and required fields, a set of required roles may 

be specified. For example, in an illustrated embodiment, roles designated as 
"EditAH", "DBConfig", and "Keyword Configure required. The "EditAH" role is 
suitably used in conjunction with Document ACL object 1 1 26 to grant editor and 
reader rights to ail documents in the database. The "DbConfig" role is suitably used 

30 to grant database-level rights to the application, and is advantageously used by any 
object that needs to restrict access to users who are owners or configurers of the 
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application. The "Keyword Config" role is suitably used to grant keyword setup rights 
to the application. The latter two roles are preferably assigned to users at the 
discretion of the developer/administrator/owner of the application. 

Although the invention has been described herein in conjunction with the 
5 appended drawings, those skilled in the art will appreciate that the scope of the 
invention is not so limited. Modifications in the selection, design, and arrangement 
of the various components and steps discussed herein may be made without 
departing from the scope of the claims. 
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CLAIMS 

1 . A method for using a programmable digital computer to create object- 
oriented applications within a non-object-oriented software environment implemented 
on said programmable digital computer, wherein said non-object-oriented software 
5 environment is configured to allow creation of an application comprising one or more 
design elements, said method comprising the steps of: 

creating, in accordance with a predetermined set of design standards, 
an object within said non-object-oriented software environment, 
wherein: 

10 said object comprises at least one of said 

design elements; 

said object is characterized by inbound public 
interfaces, outbound interfaces, and 
dependencies implemented using said 
1 5 design elements; 

transferring said object to said application; 

determining, for said object, a level of compliance to said predetermined 
set of design standards. 

2. The method of claim 1, wherein said predetermined set of design 
20 standards comprises naming standards and architectural standards. 

3. The method of claim 2, wherein said object has an object name 
associated therewith, and said naming standards specify that said name of said object 
comprises an element prefix, an object ID, and an element name. 

4. The method of claim 3, wherein said naming standards specify that said 
25 name of said object further comprises an instance number. 
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5. The method of claim 2, wherein said architects! standards comprise a 
graphical representation of said design elements configured in accordance with an 
object modeling technique. 

6. The method of claim 2, wherein said architectual standards specify an 
5 order in which said design elements should appear in said object. 

7. The method of claim 2, wherein said architectual standards specify a set 
of required design elements for said object. 

8. A system for developing an object-oriented application within a non- 
object-oriented software environment provided on a digital computer, said system 

10 comprising: 

at least one object repository for storing objects; 

an application builder configured to allow transfer of said objects from said 
object repository to said object-oriented application; 

an application analyzer for analyzing said object-oriented application and 
1 5 determining a level of compliance to a predetermined set of design standards. 

9 The system of claim 8, further comprising at least one carrier database, 
wherein said application builder is further configured to allow transfer of said objects 
from said carrier database to said repository. 

1 0. The system of claim 9, further comprising a code fragment library. 



20 



11 The system of claim 8. wherein said predetermined set of design 
standards comprises naming standards and architectual standards associated with 
said objects. 
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1 2. The system of claim 1 1 , wherein each of said objects have an object 
name associated therewith, and said naming standards specify that said object name 
comprises an element prefix, an object ID. and an element name. 

1 3. The system of claim 1 2, wherein said naming standards specify that said 
5 object name further comprises an instance number. 

1 4. The system of claim 1 1 , wherein said architectual standards comprise 
a graphical representation of said objects configured in accordance with an object 
modeling technique. 

1 5. The system of claim 1 1 , wherein said architectual standards specify an 
10 order in which said design elements should appear in said object. 

1 6. The method of claim 1 1 , wherein said architectural standards specify a 
set of required design elements for said objects. 
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